Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000101_owner-urn-ietf _Mon Mar 31 04:09:53 1997.msg

Internet Message Format | 1997-04-01 | 5KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id EAA13576
    for urn-ietf-out; Mon, 31 Mar 1997 04:09:53 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id EAA13571
    for <[e-mail]>; Mon, 31 Mar 1997 04:09:50 -0500 (EST)
Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA28884  (mail destined for [e-mail]); Mon, 31 Mar 97 04:09:48 -0500
Received: from beach.w3.org (beach.w3.org [207.8.37.250])
          by beach.w3.org (8.8.4/8.8.4) with SMTP
      id DAA26780; Mon, 31 Mar 1997 03:09:40 -0600
Message-Id: <[e-mail]>
Date: Mon, 31 Mar 1997 03:09:39 -0600
From: Dan Connolly <[e-mail]>
Organization: World Wide Web Consortium
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: Daniel LaLiberte <[e-mail]>
Cc: "Ron Daniel, Jr." <[e-mail]>, [e-mail]
Subject: Re: [URN] Relative URNs considered harmful
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Dan Connolly <[e-mail]>
Errors-To: [e-mail]

Daniel LaLiberte wrote:
> Ron Daniel, Jr. writes:
>  > During the earlier set of discussions my view on relative
>  > URNs changed from "unnecessary but probably harmless" to
>  > "unnecessary and probably harmful". Let me explain why.

I'll buy that check digits and relative URIs don't mix.
For the ISBN: scheme, we have to pick one. This
is a tradeoff between human-friendliness vs. functionality:
check digits imporove man-machine reliability, while hierarchical
names support scalable resolution, as Daniel says.

(R. Daniel, Daniel L, and Daniel C. -- lots of Dan's around here! :-)


> --------------
>
> Now for the main reason that I believe relative URNs should be
> supported.  First, the reason is not so much for support of relative
> URNs themselves.  As much as they are useful, they are not essential
> since full URNs and relative URLs can be used too.  The real reason is
> that because relative URNs (of the hierarchical kind) require a
> publically visible hierarchy, that same hierarchy can be used by
> clients to support more scalable resolution.

That's my intuition too: there's a note in the NAPTR draft
about "the number of DNS queries approach one" that seems
VERY important.

I really want to see the details of the statistical
argument behind it.


> A principle I stated earlier that you agreed to is that with an ever
> increasing number of users, more of the work of resolving identifiers
> must be done by clients or servers near the clients. ...

Absolutely!

To put it another way: hierarchy is necessary to exploit
locality of reference, which is essential to scalability.

On the other hand, as I start to grok NAPTR fully, I realize
that it's about dynamically extending the URI naming conventions:

-----------------
http://services.bunyip.com:8000/research/ietf/urn-bof/urnframework.txt
draft-ietf-daigle-urnframework-00.txt

the Namespace ID is used to
determine the _syntactic_ interpretation of the Namespace Specific
String to
the extent of extracting the Naming Authority information.
-----------------


Hmmm... all this regexp stuff is cool, but in order
to exploit locality of reference, we have to be able to
parse addresses from the other direction: from the
leaves toward the root. I'm suddenly perplexed as
to how to do that with NAPTR.


> With a hierarchically structured name space, resolution of an
> identifier can proceed by first looking up information in local caches
> about resolvers or RDSs for the most specific known subspace
> corresponding to some prefix of the identifier.  Only then do we need
> to ask remote servers to resolve the remainder, or look up resolvers,
> or whatever needs to be done.

DNS is one obvious example of this principle in action.
The COM Compose Moniker is another example:


----------------
http://www.microsoft.com/oledev/olecom/Ch11.htm#GenericComposite

Generic Composite Moniker-IMoniker::BindToObject

 Binding to a generic composite works in a right-to-left manner.
 Conceptually, the generic composite merely forwards the bind
 request onto its last piece, along the way informing that piece
of the moniker to its left in the composite. The last piece, if it
 needs to,
 recursively binds to the object to its left. In practice, binding
to a generic composite itself has to handle the recursive call on
the left-hand object, as was described in IMoniker::BindToObject.
-----------------

> Until there is a strong enough argument
> for how non-hierarchical name spaces can support scalable resolution,
> I would hesitate to disallow hierarchical name spaces.

That makes a lot of sense.

--
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21